鉴书堂 | 《事半功倍的工作艺术》
江北，加拿大英属哥伦比亚大学博士
可持续生活倡导者
事半功倍，听上去很诱人。
今天我要介绍的书和工作方法有关。它让我反思自己曾经从事的行业为什么从高端市场高收入，渐渐走向低端竞争低效率。没错，我说的就是建筑与城市规划设计咨询行业，简称设计咨询。
中国的城市规划脱胎于计划经济。国家有五年计划，按计划执行，总该万无一失了吧？当然不是！
市场经济，资本当先。市场经济下的设计咨询行业，面临的最大挑战是需求变量：客户变更需求，会造成设计团队反复修改，成本增加；重要项目的婆婆多、验收关卡多，目标变量不可控。
项目管理成功，意味着团队能按时交付客户满意的产品，同时有所盈利。
设计咨询行业，最大的成本是人力：时薪x工作时长=人力成本。
我知道有很多设计咨询机构，都不会因为成本超支叫停项目，而是一边跟客户软磨硬泡补签合同追尾款，一边放任设计师超长加班，稀释时薪。如此一来，设计咨询行业渐渐落入试探客户需求、生产力低下的恶性循环。
我今天介绍的这本书，启发我们在项目偏离轨道时，如何通过迭代和调整，重回正轨。
The Art of Doing Twice the Work in Half the Time
《争球：事半功倍的工作艺术》
by Jeff Sutherland
Currency, 2014
阅读难度 ♥♥♡♡♡
参考价值 ♥♥♥♡♡
美国FBI在2000年开发了一款刑事案件网络管理系统。这个项目的预算超过1.7亿美元，然而经过5年的研发，项目却以失败告终。上百个软件工程师写的70万行代码，最终因为没有可展示的产品统统作废。
如此重要的项目，为何落得这般下场？
原因有很多，系统设计不当、糟糕的项目管理……但归根结底是因为选择了一种笨重的工作方法。
当时的FBI，创建了一个面面俱到、体量庞大的启动计划。项目仅创建需求一项，就动用了300个人花6个月起草，写成600页的“需求描述”文档、400个“变更申请”文档。
项目失败后FBI不得不换种方法，把项目分解成600个用户故事，以不超过15人的轻型团队组织工作，而不是之前的300人。由产品经理为任务确定优先级并派发给团队，每个任务周期不超过两周，结束前要作演示。
结果呢？只用了不到一半的预算，项目在两年内就成功了！这之后联邦特工们一直在案件调查中使用这个系统。
FBI后来用的这种工作方法，借鉴了软件开发者常用的scrum（直译“争球”）【“争球”在橄榄球比赛中是一种技术动作；在IT领域指一种快速、敏捷的软件开发流程。——编者注】。
它的核心动作是定期喊停，让项目参与人员反思已经做过什么，确定接下来要做什么；
共同商讨遇到哪些障碍；
对下一步工作的分工协作达成共识。
《争球：事半功倍的工作艺术》详细介绍了scrum工作法。作者杰夫・萨瑟兰（Jeff Sutherland）是一名企业家，很擅长讲故事，他讲述自己如何用这套方法拯救了耗资亿计的火箭飞船制造项目，扭转亏损的洗衣店、婚礼策划生意。萨瑟兰的生意经里，最重要的是准时交付。
他把工作方式分为两类：瀑布法和敏捷法。
瀑布法侧重于线性的项目管理，比如汽车生产流水线。其特点是：项目被分解成若干段，只有上一阶段所有工作完成后才能进入下一阶段；必须罗列所有需求才进入实施；客户拿到最终产品之前，几乎没有任何反馈。
电影《摩登时代》里展现生产线工人的工作状态
建一座大楼、批量生产牛仔裤……瀑布法是适用的。因为这些任务都经过漫长的前期分析，很少中途变更需求。
但是，还有些工作依赖用户反馈，不能从一开始就对产品提出精准的要求，比如开发手机app、写网络小说。若想完成这些任务，必须对变化有很强的适应力。这就需要用到跟瀑布法相反的敏捷法。
敏捷法倾向于将项目作为一个整体来处理，而不是切成不同阶段。工作的组织围绕任务节点而非文本。所以这种方法项目前期的管理文档很少，分析用时更短，允许客户全程参与。
靠敏捷法取得成功的典型是微信。不求一步到位，1.0版上市后不断测试、获得用户反馈，持续调整、增加新功能。
值得一提的是，用敏捷法组织工作用的是sprint冲刺，每次冲刺最终都有可交付的成果。冲刺以周为单位，从一周到四周不等。开发团队在冲刺中磨合协调，不断吸收客户反馈，及时捕捉错误，交付客户最想要的产品。冲刺里有局部没能如期完成的任务也无伤大雅，它们很可能会被项目经理整理到下一个冲刺。
总之，这种工作方式相对灵活，不作没成果可展示的消耗动作。
两种工作方式，归根结底是两种风险控制术。
在过去，作家写一本书可能要花上一年，然后送出版社编辑印刷上架。若想知道市场反响如何，通常要再等半年看销售数据。这样的反馈速度太慢，出版社为了降低风险，倾向于和已经在市场上占得先机的知名作家签约。
可网络文学不是这样。网络作家写一部作品，会从后台读取大量信息，看阅读量、点赞和评论，小说剧情的走向也由读者参与决策、作家执笔完成。网络小说家要想成功，必须能及时满足粉丝，于是一流的网络小说家练就了日更万字、不断涨粉的本领。粉丝对一部连载作品买不买账，只需要两三个月，甚至更短就知道了。
传统作家用的是瀑布法。它不大考虑项目过程中的变量，依赖初始计划（创作大纲）的完备性，一旦初始需求设定有缺陷，与市场要求脱节，项目几乎注定失败。另外，产品直到项目结束后才接受测试，若是在临近结束时发现重大失误，不得不付出高昂的代价，否则满盘皆输。
相比之下，网络写手用的敏捷法更灵活，允许读者在中途变更需求、添加功能（人物、剧情、彩蛋），以便让产品跟上行业发展。
总结起来就是：对于需要大规划社会协作、任务定义和客户期待都很明确的项目，瀑布法很好；敏捷法则适用于客户需求不断调整、持续改进、反馈周期短的项目。
只要跟人打交道，就难免有混乱、非标准的因素。我不相信有神奇贴药能包治百病，或者任何一种工作方法能解决所有企业的管理难题。本书作者也指出：如果敏捷法对你的公司没起什么作用，可能是有没做对的地方。
嗯，这听上去像是句废话。
我认为作者不够诚恳，书中没提到任何敏捷法失灵的例子。失败本身并没有那么可怕，但作者避而不谈，就让这种方法的正当性打了折扣。
企业和组织领导者在选择敏捷法时，应该获得充分的知情权，那就是这种方法有其消极方面，比如它对产品经理、创作者的素质要求非常高。产品经理，要提前规划；所有创作者（比如软件工程师），能主动思考。
另外，它会经常改变计划，需要团队内部及客户充分信任，否则会损害稳定性。
反过来看，瀑布法也并不坏，它对许多行业仍然非常重要。无论选取哪种方法，都要面对一个现实，就是现代社会的很多任务，需求会一路变化。
新的方法给我们哪些启示？
我观察到，这些年来设计咨询行业自降身价、延时工作已成家常便饭。长此以往，只会伤害团队的专业价值。设计主创们长期疲劳工作，判断力下降，很难持续高水准的创作和学习成长。
与此同时，我们也看到行业内部悄然变化，有不少专业口碑好、生命力旺盛、实力扩张的设计团队，已经把参与感和适应性列入行业发展风向标。我认识的一些团队，甚至借鉴了软件开发团队常用的工作方法，比如：
公司内部设立项目经理负责生产经营，让资深设计师专心做设计； 项目经理在拿到项目后，花一天时间把新项目分解成若干可交付产品； 每个产品允许一个人在8~80小时完成，避免保姆式的细微管理（micro-management）； 每个工作日上岗的前15分钟，有项目经理牵头开小组碰头会，短平快逐一发言，确认成员工作进度、反馈困难，确定当日工作目标； 会后，项目经理就大家反映的困难逐一给出解决方案，比如与客户沟通确认、寻求专业增援； 客户高频参与交付成果的确认和反馈，以便设计小组及时调整方向。
改良工作方法，更好地适应复杂变化。在项目推进过程中，不断提交可交付的最小化产品，与客户保持信息透明，让进度和投入成本可见。
这就是我从软件工程师的工作方法中获得的启发。
我们为什么需要公园？
编辑、排版：张祎娴